第八条:理解"对象同等性"这一概念

根据“等同性”(equality)来比较对象是一个非常有用的功能。不过,按照==操作符比较出来的结果未必是我们想要的,因为该操作比较的是两个指针本身,而不是其所指的对象。应该使用NSObject协议中声明的“isEqual”:方法来判断两个对象的等同性。一般来说,两个类型不同的对象总是不相等的(unequal)。某些对象提供了特殊的“等同性判定方法”(equality-checking method),如果已经知道两个受测对象都属于同一个类,那么就可以使用这种方法。以下述代码为例:


NSString *foo = @"Badger 123";
NSString *bar = [NSStringstringWithFormat: @fTBadger %i", 123】;
BOOL equalA = (foo == bar); //< equal A - NO
BOOL equalB = [foo isEqual: bar ] ; //< equalB = YES
BOOL equalC = [foo isEqualToString:bar]; //< equalC = YES

上面可以看到==与等同性判断方法之间的差别。NSString类实现了一个自己独有的等同性判断方法,名叫“isEqualToString:”。传递给该方法的对象必须是NSString,否则结果未定义(undefined)。调用该方法比调用“isEqual”方法快,后者还要执行额外的步骤,因为它不知道受测对象的类型(前者指使用NSString所以快些)。

NSObject协议中有两个用于判断等同性的关键方法:


- (BOOL) isEqual: (id) object;
- (NSUInteger) hash;

NSObject类对这两个方法的默认实现是:当且仅当其“指针值"(pointer value)(内存地址)完全相等时,这两个对象才相等。若想在自定义的对象中正确覆写这些方法,就必须先理解其约定
(contract)。如果“isEqual:”方法判定两个对象相等,那么其hash方法也必须返回同一个值。但是,如果两个对象的hash方法返回同一个值,那么“isEqual:”方法未必会认为两者相等。

比如有下面这个类:


@interface EOCPerson : NSObject
@property (nonatomic, copy) NSString *firstName;
@property (nonatomic, copy) NSString *lastName;
@property (nonatomic, assign) NSUInteger age;
@end

我们认为,如果两个EOCPerson的所有字段均相等,那么这两个对象就相等。于是“isEqual:”方法可以写成:


-(BOOL)isEqual:(id)object {
    if (self == object) return YES;
    if ( [self class] != [object class]) return NO;
    EOCPerson ^otherPerson = (EOCPerson*)object;
    if (! [_firstName isEqualToString:otherPerson.firstName))
    return NO;
    if (![_lastName isEqualToString:otherPerson.lastName])
    return NO;
    if (_age != otherPerson.age)
    return NO;
    return YES;
}

首先,直接判断两个指针是否相等。若相等,则其均指向同一对象,所以受测的对象也必定相等。接下来,比较两对象所属的类。若不属于同一个类,则两对象不相等。EOCPerson对象当然不可能与EOCDog对象相等。不过,有时我们可能认为:一个EOCPerson实例可以与其子类(比如EOCSmithPerson)实例相等。在继承体系(inheritance hierarchy)中判断等同属性时,经常遭遇此类问题.所以实现"isEqual:"方法时要考虑到这种情况。最后,检测每个属性是否相等。只要其中有不相等的属性,就判定两对象不等,否则两对象相等。

接下来,我们实现hash方法.回想一下,根据等同性约定:若两对象相等,则其哈希码(hash)也相等,但是两个哈希码相同的对象却未必相等。这是能否正确覆写“isEqual”方法的关键所在。下面这种写法完全可行:


-(NSUInteger)hash {
    return 1337;
}

collection中使用这种对象将产生性能问题,因为collection在检索哈希表(hash table)时,会用对象的哈希码做索引。假如某个collection是用set实现的,那么set可能会根据哈希码把对象分装到不同的数组中。在向set中添加新对象时,要根据其哈希码找到与之相关的那个数组,依次检査其中各个元素,看数组中已有的对象是否和将要添加的新对象相等。如果相等,那就说明要添加的对象已经在set里面了。如果令每个对象都返回相同的哈希码,那么在set中已有1000000个对象的情况下,若是继续向其中添加对象,则需将这1 000000个对象全部扫描一遍。

我们看另一种计算哈希码的方法:


-(NSUInteger)hash {
    NSUInteger firstNameHash = [_firstName hash];
    NSUInteger lastNameHash = [_lastName hash];
    NSUInteger ageHash = _age;
    return firstNameHash ^ lastNameHash ^ ageHash;
}

这种做法既能保持较高效率,又能使生成的哈希码至少位于一定范围之内,而不会过于频繁地重复。当然,此算法生成的哈希码还是会碰撞(collision),不过至少可以保证哈希码有多种可能的取值.编写hash方法时,应该用当前的对象做做实验,以便在减少碰撞频度与降低运算复杂程度之间取舍。

特定类所具有的等同性判定方法

除了刚才提到的NSString之外,NSArrayNSDictionary类也具有特殊的等同性判定方法,前者名为“isEqualToArray:”,后者名为“isEqualToDictionary:”。如果和其相比较的对象不是数组或字典,那么这两个方法会各自抛出异常。由于Objective-C在编译期不做强类型检査(strong type checking),这样容易不小心传入类型错误的对象,因此开发者应该保证所传对象的类型是正确的。

如果我们觉得提供的判断方法不好用,可以自己来写一个,令代码看上
去更美观、更易读,使自己编写的判定方法更容易读懂,而且不用再检査两个受测对象的类型了。

在编写判定方法时,也应一并覆写“isEqual:”方法。后者的常见实现方式为:如果受测的参数与接收该消息的对象都属于同一个类,那么就调用自已编写的判定方法,否则就交由超类来判断。

例如:


- (BOOL)isEqualToPerson:(EOCPerson*)otherPerson {
if (self == object) return YES;
    if (! [_firstName isEqualToString:otherPerson.firstName])
        return NO;
    if (![_lastName isEqualToString:otherPerson.lastName])
        return NO;
    if (_age != otherPerson.age)
        return NO;
    return YES;
}

-(BOOL)isEqual:(id)object {
    if ([self class] == [object class]) {
        return [self isEqualToPerson:(EOCPerson*)object];
    } else {
        return [super isEqual:object】;

等同性判定的执行深度

创建等同性判定方法时,需要决定是根据整个对象来判断等同性,还是仅根据其中几个字段来判断。NSArray的检测方式为先看两个数组所含对象个数是否相同,若相同,则在每个对应位置的两个对象身上调用其“isEqual”方法。如果对应位置上的对象均相等,那么这两个数组就相等,这叫做“深度等同性判定”(deep equality)。不过有时候无须将所有数据
逐个比较,只根据其中部分数据即可判明二者是否等同。

比方说,我们假设EOCPerson类的实例是根据数据库里的数据创建而来,那么其中就可能会含有另外一个属性,此属性是“唯一标识符"(unique identifier),在数据库中用作“主键”


@property NSUInteger identifier;

在这种情况下,我们也许只会根据标识符来判断等同性,尤其是在此属性声明为readonly时更应该如此。因为只要两者标识符相同,就肯定表示同一个对象,因而必然相等。
这样的话,无须逐个比较EOCPerson对象的每条数据,只要标识符相同,就说明这两个对象就是由同一个数据源所创建的,据此我们能够断定,其余数据也必然相同。

容器中可变类的等同性

还有一种情况一定要注意,就是在容器中放入可变类对象的时候。把某个对象放入collection之后,就不应再改变其哈希码了。前面解释过,collection会把各个对象按照其哈希码分装到不同的“箱子数组”中。如果某对象在放入“箱子”之后哈希码又变了,那么其现在所处的这个箱子对它来说就是“错误”的。要想解决这个问题,需要确保哈希码不是根据对象的“可变部分”(mutable portion)计算出来的,或是保证放入collection之后就不再改变对象内容了。之后将在第18条中解释为何要将对象做成“不可变的"(immutable)。

要点:

  • 若想检测对象的等同性,请提供“isEqual:”hash方法。
  • 相同的对象必须具有相同的哈希码,但是两个哈希码相同的对象却未必相同。
  • 不要盲目地逐个检测每条属性,而是应该依照具体需求来制定检测方案。
  • 编写hash方法时,应该使用计算速度快而且哈希码碰撞几率低的箅法。
2017/7/3 posted in  第二章 对象,消息,运行期

第七条 在对象内部尽量直接访问实例变量

在对象之外访问实例变量时,总是应该通过属性来做,然而在对象内部访问实例变量时,除了几种特殊情况之外,强烈建议大家在读取实例变量的时候采用直接访问的形式,而在设置实例变量的时候通过属性来做

下面举个例子:


@interface EOCPerson : NSObject
@property (nonatomic, copy) NSString *firstName;
@property (nonatomic, copy) NSString *lastName;

// Convenience for firstName + ” ” 十 lastName:
-(NSString*)fullName;
-(void)setFullName:(NSString*) fullName;
@end

fullName与setFullName这两个“便捷方法”可以这样来实现:


-(NSString*)fullName {
    return [NSString stringWithFormat: @"%@ %@",
            self.firstName, self.lastName];
/** The following assumes all full names have exactly 2
*   parts. The method could be rewritten to support more
* exotic names.
*/
-(void)setFullName: (NSString*)fullName {
    NSArray *components = [fullName componentsSeparatedByString:@" "];

    self.firstName = [components objectAtIndex: 0];
    self.lastName = [components objectAtIndex:1];
}

然后我们改写上面的例子:


-(NSString*)fullName {
    return [NSString stringWithFormat: @"%@ %@",
            _firstName, _lastName];

-(void)setFullName:(NSString*)fullName {
        NSArray *components = [fullName componentsSeparatedByString:@" "];

    _firstName = [components objectAtIndex: 0];
    _lastName = [components objectAtIndex:1];
}

这两种写法各有优点和缺点:

  • 由于不经过Objective-C的“方法派发” (method dispatch,之后第11条)步骤,所以直接访问实例变量的速度当然比较快。在这种情况下,编译器所生成的代码会直接访问保存对象实例变量的那块内存。

  • 直接访问实例变童时,不会调用其“设置方法”,这就绕过了为相关属性所定义的“内
    存管理语义”。比方说,如果在ARC下直接访问一个声明为copy的属性,那么并不
    会拷贝该属性,只会保留新值并释放旧值。

  • 如果直接访问实例变量,那么不会触发‘键值观测’(Key-Value Observing,KVO)通知。这样做是否会产生问题,还取决于具体的对象行为。

  • 通过属性来访问有助于排査与之相关的错误,因为可以给“获取方法”和/或“设置
    方法”中新增“断点"(breakpoint),监控该属性的调用者及其访问时机。

因为各有好处,这里我们就找一个折中方案:写入实例变量时,通过其“设置方法”来做,而在读取实例变量时,则直接访问之。此办法既能提高读取操作的速度,又能控制对属性的写入操作。之所以要通过“设置方法”来写人实例变量,其首要原因在于,这样做能够确保相关属性的“内存管理语义”得以贯彻。但是,选用这种做法时,需注意几个问题:

第一个要注意的地方就是,在初始化方法中应该如何设置属性值。这种情况下总是应
直接访问实例变量,因为子类可能会“覆写”(override)设置方法。假设EOCPerson有一个子类叫做EOCSmithPerson,这个子类专门表示那些姓“Smith”的人。该子类可能会覆写lastName属性所对应的设置方法:


-(void)setLastName:(NSString*)lastName {
    if (![lastName isEqualToString:@"Smith"]){
      [NSException raise:NSInvalidArgumentException
                  format:@"Last name must be Smith"];
}
    self.lastName = lastname; //这里没有直接访问,而是用的点语法.(最好直接访问)
}

在基类EOCPerson的默认初始化方法中,可能会将姓氏设为空字符串。此时若是通过
“设置方法”来做,那么调用的将会是子类的设置方法,从而拋出异常。但是,某些情况下却又必须在初始化方法中调用设置方法:如果待初始化的实例变量声明在超类中,而我们又无法在子类中直接访问此实例变量的话,那么就需要调用“设置方法”了。

第二个注意问题"惰性初始化"(lazy initialization)。在这种情况下,必须通过“获取方法”来访问属性,否则,实例变量就永远不会初始化。比方说,EOCPerson类也许会用一个属性来表示人脑中的信息,这个属性所指代的对象相当复杂。由于此属性不常用,而且创建该属性的成本较高,所以,我们可能会在“获取方法”中对其执行惰性初始化:


-(EOCBrain)brain {
    if (!_brain) {
        brain = [Brain new];    //若没有调用获取方法,这句话永远也不会执行,去初始化
    }
    return _brain;

若没有调用“获取方法”就直接访问实例变量,则会看到尚未设置好的brain,所以说,
如果使用了“惰性初始化”技术,那么必须通过存取方法来访问brain属性。

要点

  • 在对象内部读取数据时,应该直接通过实例变量来读,而写入数据时,则应通过属性
    来写。

  • 在初始化方法及dealloc方法中,总是应该直接通过实例变量来读写数据。

  • 有时会使用惰性初始化技术配置某份数据,这种情况下,需要通过属性的"获取方法"来读取数据。

2017/6/30 posted in  第二章 对象,消息,运行期

第六条 理解"属性" 这一概念

用Objective-C等面向对象语言编程时,“对象”(object)就是“基本构造单元"(building block),开发者可以通过对象来存储并传递数据。在对象之间传递数据并执行任务的过程就叫做“消息传递”(Messaging)。若想编写出髙效且易维护的代码,就一定要熟悉这两个特性的工作原理。

当应用程序运行起来以后,为其提供相关支持的代码叫做“Objective-C运行期环境”(Objective-C runtime),它提供了一些使得对象之间能够传递消息的重要函数,并且包含创建类实例所用的全部逻辑。在理解了运行期环境中各个部分协同工作的原理之后,你的开发水
平将会进一步提升。

属性

“属性”(property)是Objecive-C的一项特性,用于封装对象中的数据。Objective-C对象通常会把其所需要的数据保存为各种实例变量。实例变量一般通过“存取方法”(access method)来访问。其中,“获取方法"(getter)用于读取变量值,"设置方法"(setter)用于写入变量值。这个概念已经定型,并且经由“属性”这一特性而成为Objective-C 2.0的一部分,开发者可以令编译器自动编写与属性相关的存取方法。此特性引入了一种新的“点语法”(dot syntax),使开发者可以更为容易地依照类对象来访问存放于其中的数据。你也许已经使用过“属性”这个概念了,不过你未必知道其全部细节。而且,还有很多与属性有关的麻烦事。第6条将会告诉大家有哪些问题可以用属性来解决,并指出其中所体现出来的关键特性。在描述个人信息的类中,也许会存放人名、生日、地址等内容。可以在类接口的public
区段中声明一些实例变量:


@interface EOCPerson : NSObject {
@public
    NSString *_firstName;
    NSString *_lastName;
@private
    NSString *_someInternalData;
}
@end

这种写法在其他语言中,java或者c++中比较常见,但是编写Objective-C代码时却很少这么做。这种写法的问题是:对象布局在编译期(compile time)就已经固定了。只要碰到访问firstName变量的代码,编译器就把其替换为“偏移量”(offset),这个偏移量是“硬编码”(hardcode),表示该变M距离存放对象的
内存区域的起始地址有多远。

这种写法的问题是,如果又增加一个实例变量,就麻烦了,例如:


@interface EOCPerson : NSObject {
@public
    NSString *_dataOfBirth;
    NSString *_firstName;
    NSString *_lastName;
@private
    NSString *_someInternalData;
}
@end

原来表示_firstName的偏移量现在却指向dateOfBirth了。把偏移量硬编码于其中的那些代码都会读取到错误的值。

如果代码使用了编译期计算出来的偏移量,那么在修改类定义之后必须重新编译,否则就会出错。

例如,某个代码库中的代码使用了一份旧的类定义。如果和其相链接的代码使用了新的类定义,那么运行时就会出现不兼容现象(incompatibility)。各种编程语言都有应对
此问题的办法。Objective-C的做法是,把实例变量当做一种存储偏移量所用的“特殊变量”(special variable),交由“类对象”(class object)保管。偏移量会在运行期査找,如果类的定义变了,那么存储的偏移量也就变了,这样的话,无论何时访问实例变量,总能使用正确的偏移最。甚至可以在运行期向类中新增实例变量,这就是稳固的“应用程序二进制接口”(Application Binary Interface,ABI)。有了这种“稳固的”(nonfragile)的ABI,我们就可以在“class-continuation分类”或实现文件中定义实例变量了。所以说,不一定要在接口中把全部实例变量都声明好,可以将某些变量从接口的public区段里移走,以便保护与类实现有关的内部信息

下面我们就要来讨论另一种解决方法,也就是"属性",我们尽量不要直接访问实例变量,而应该通过存取方法来做。虽说属性最终还是得通过实例变量来实现,但它却提供了一种简洁的抽象机制。你可以自己编写存取方法,然而在正规的Objective-C编码风格中,存取方法有着严格的命名规范。正因为有了这种严格的命名规范,所以Objective-C这门语言才能根据名称自动创建出存取方法。这时@property语法就派上用场了。

在对象接口的定义中,可以使用属性,这是一种标准的写法,能够访问封装在对象里的数据。因此,也可以把属性当做一种简称,其意思是说:编译器会自动写出一套存取方法,用以访问给定类型中具有给定名称的变量。,例如下面这个类:


@interface EOCPerson : NSObject
@property NSString *firstName;
@property NSString *lastName;

@end

对于该类的使用者来说,上述代码写出来的类与下面这种写法等效:


@interface EOCPerson : NSObject
- (NSString*)firstName;
- (void) setFirstName: (NSString*) firstName;
- (NSString*)lastName;
- (void)setLastName:(NSString*)lastName;
@end

要访问属性我们可以使用点语法,与c语言类似.使用“点语法”和直接调用存取方法之间没有丝毫差别:


EOCPerson *aPerson = [Person new];
aPerson.firstName = @"Bob"; //Same as:
[aPerson setFirstName:@"Bob"];

NSString *lastName = aPerson.lastName; //Same as:
NSString *lastName = [aPerson lastName];

如果使用了属性的话,编译器会自动编写这些属性的访问方法.此过程叫做“自动合成”(autosynthesis)。需要强调的是,这个过程由编译器在编译期执行,所以编辑器里看不到这些“合成方法"(synthesized method)的源代码。

编译器还会自动向类中添加适当的实例变量,并且在属性名前面加下划线,以此作为实例变量的名字.在前例中,会生成两个实例变量,其名称分别为_firstName与_lastName。也可以在类的实现代码里通过@synthesize语法来指定实例变量的名字:


@implementation EOCPerson
@synthesize firstName = _myFirstName;
@synthesize lastName = _myLastName;
@end

前述语法会将生成的实例变量命名为_myFirstName与_myLastName,而不再使用默认的名字。

若不想令编译器自动合成存取方法,则可以自己实现。如果你只实现了其中一个存取方法,那么另外一个还是会由编译器来合成。还有一种办法能阻止编译器自动合成存取方
法,就是使用@dynamic关键字,它会告诉编译器:不要自动创建实现属性所用的实例变量,也不要为其创建存取方法。而且,在编译访问属性的代码时,即使编译器发现没有定义存取方法,也不会报错,它相信这些方法能在运行期找到。比方说,如果从CoreData框架中的NSManagedObject类里继承了一个子类,那么就需要在运行期动态创建存取方法。继承NSManagedObject时之所以要这样做,是因为子类的某些属性不是实例变量,其数据来自后端的数据库中。所以:


@interface EOCPerson : NSManagedObject
@property NSString *firstName;
@property NSString *lastName;
@end

@implementation EOCPerson
@dynamic firstName, lastName;

@end

编译器不会为上面这个类自动合成存取方法或实例变量。如果用代码访问其中的属性,编译器也不会发出警示信息.

属性特质

使用属性时还有一个问题要注意,就是其各种特质(attribute)设定也会影响编译器所生成的存取方法。比如下面这个属性就指定了三项特质:


@property (nonatomic, readwrite, copy) NSString * 
firstName;

属性可以拥有的特质分为四类:

  1. 原子性:
    在默认情况下,由编译器所合成的方法会通过锁定机制确保其原子性(atomicity) 。如果属性具备nonatomic特质,则不使用同步锁。请注意,尽管没有名为“atomic”的特质(如果某属性不具备nonatomic特质,那它就是“原子的”(atomic)),但是仍然可以在属性特质中写明这一点,编译器不会报错。若是自己定义存取方法,那么就应该遵从与属性特质相符的原子性。

  2. 读/写权限:

    • 具备readwrite(读写)特质的属性拥有“获取方法”(getter)与“设置方法"(setter)。若该属性由@synthesize实现,则编译器会自动生成这两个方法。
    • 具备readonly(只读)特质的属性仅拥有获取方法只有当该属性由@synthesize实现时,编译器才会为其合成获取方法。你可以用此特质把某个属性对外公开为只读属性,然后在“class-cominuaticm分类”中将其重新定义为读写属性。后面再详述这种做法。
  3. 内存管理语义:
    属性用于封装数据,而数据则要有“具体的所有权语义”(concrete ownership semantic)。下面这一组特质仅会影响“设置方法”(setter)。例如,用“设置方法”设定一个新值时,它是应该“保留"(retain)此值呢,还是只将其赋给底层实例变量就好?编译器在合成存取方法时,要根据此特质来决定所生成的代码。如果自己编写存取方法,那么就必须同有关属性所具备的特质相符

    • assign “设置方法”只会执行针对“纯量类型”(scalar type,例如CGFloat或NSImeger等)的简单赋值操作。
    • strong 此特质表明该属性定义了一种“拥有关系”(owning relationship)。为这种属性设置新值时,设置方法会先保留新值,并释放旧值,然后再将新值设置上去。
    • weak 此特质表明该属性定义了一种“非拥有关系”(nonowning relationship)。为这种属性设置新值时,设置方法既不保留新值,也不释放旧值。此特质同assign类似,然而在属性所指的对象遭到摧毁时,属性值也会清空(nil out)。
    • unsafe_unretained 此特质的语义和assign相同,但是它适用于“对象类型”(object type),该特质表达一种“非拥有关系”(“不保留”,unretained),当目标对象遭到摧毁时,属性值不会自动清空(“不安全”,unsafe),这一点与weak有区别
    • copy 此特质所表达的所属关系与strong类似。然而设置方法并不保留新值,而是将其“拷贝”(copy)。当属性类型为NSString*时,经常用此特质来保护其封装性,因为传递给设置方法的新值有可能指向一个NSMutableString类的实例。这个类是NSString的子类,表示一种可以修改其值的字符串,此时若是不拷贝字符串,那么设置完属性之后,字符串的值就可能会在对象不知情的情况下遭人更改。所以,这时就要拷贝一份“不可变”(immutable)的字符串,确保对象中的字符串值不会无意间变动。只要实现属性所用的对象是“可变的”(mutable),就应该在设置新属性值时拷贝一份.
  4. 方法名:
    可通过如下特质来指定存取方法的方法名:

  • getter= 指定“获取方法”的方法名。如果某属性是Boolean型,而你想为其获取方法加上“is”前缀,那么就可以用这个办法来指定。比如说,在UISwitch类中,表示“开关"(switch)是否打开的属性就是这样定义的:

@property (nonatomic, getter=isOn) BOOL on;

  • setter= 指定"设置方法"的方法名.(不太常见)

    通过上述特质,可以微调由编译器所合成的存取方法。不过需要注意:若是自己来实现这些存取方法,那么应该保证其具备相关属性所声明的特质。比方说,如果将某个属性声明为copy,那么就应该在“设置方法”中拷贝相关对象,否则会误导该属性的使用者,而且,
    若是不遵从这一约定,还会令程序产生bug。

如果想在其他方法里设置属性值,那么同样要遵守属性定义中所宣称的语义。例如,我们扩充一下前面提到的EOCPerson类。由于字符串值可能会改变,所以要把相关属性的“内存管理语义"声明为copy。该类中新增了一个‘初始化方法’(initializer),用于设置“名"(first name)和“姓”(last name)的初始值:


@interface EOCPerson : NSManagedObject
@property (copy) NSString *firstName;
©property (copy) NSString *lastName;

- (id)initWithFirstName: (NSString*)firstName
                lastName:(NSString*)lastName;
@end

在实现这个自定义的初始化方法时,一定要遵循属性定义中宣称的“copy”语义,因为“属性定义”就相当于“类”和“待设置的属性值”之间所达成的契约。初始化方法的实现代码可以这样写:


- (id)initWithFirstName: (NSString*) firstName
                lastName:(NSString*)lastName
{
    if ((self = [super init])) {
        _firstName = [firstName copy];
         _lastName = [lastName copy];
    }
return self;
}

这里也许会有疑问:为何不调用属性所对应的“设置方法”呢?如果用了“设置方法”的话,不是总能保证准确的语义吗?后面第7条学习中将会详细解释为什么决不应该在init(或dealloc)方法中调用存取方法

要是看过第18条的话,你就会明白,应该尽量使用不可变的对象。如果将这一条套用到EOCPerson类身上,那就等于说,其两个属性都应该设为“只读”。用初始化方法设置好属性值之后,就不能再改变了。在本例中,仍需声明属性的“内存管理语义”。于是可以把属性的定义改成这样:


@property (copy, readonly) NSString *firstName;
@property (copy, readonly) NSString *lastName;

由于是只读属性,所以编译器不会为其创建对应的“设置方法”,即便如此,我们还是要写上这些属性的语义,以此表明初始化方法在设置这些属性值时所用的方式。要是不写明语义的话,该类的调用者就不知道初始化方法里会拷贝这些属性,他们有可能会在调用初始化方法之前自行拷贝属性值。这种操作是多余而且低效的。

atomic与nonatomic的区别就是是否具有原子性,具备atomic特质的获取方法会通过锁定机制来确保其操作的原子性。避免两个进程同时访问同一属性时,读取到其它线程没有修改好的属性值.

在ios开发中,其中所有属性都声明为ncmatomic。这样做的历史原因是:在iOS中使用同步锁的开销较大,这会带来性能问题。一般情况下并不要求属性必须是“原子的”,因为这并不能保证“线程安全"(thread safety),若要实现“线程安全”的操作,还需采用更为深层的锁定机制才行。

要点:

  • 可以用@property语法来定义对象中所封装的数据。
  • 通过“特质”来指定存储数据所需的正确语义。
  • 在设置属性所对应的实例变量时,一定要遵从该属性所声明的语义。
  • 开发iOS程序时应该使用nonatomic属性,因为atomic属性会严重影响性能。
2017/6/28 posted in  第二章 对象,消息,运行期